1. Plan
2. Avant-propos
Nous allons nous intéresser dans ce cours aux Méthodologies de la Production d'Application.
Ce module, qui fait suite aux modules de programmation (M2103), conception (M2104) et d’IHM (M2105), est fortement corrélé au module de conception avancé (M3105).
|
Nous suivons (comme tous les DUT informatique) le programme pédagogique national (PPN - disponible ici). |
2.1. À qui est destiné ce document?
Les étudiants du DUT informatique, mes collègues enseignants qui cherchent un document de référence accessible, et … moi-même (pour organiser mes notes diverses)!
2.2. À qui il n’est pas destiné?
Si vous appartenez à une de ces catégories, ce document n’est pas pour vous :
2.3. Historique
Ce document est tout nouveau (date de naissance 05/09/2014!), donc merci de votre indulgence …
Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.
2.4. Sur l’auteur
-
Professeur à l’Université de Toulouse, en poste à l’IUT de Blagnac
-
Co-fondateur de l’association SysML-France
-
Membre du comité éditorial de la revue SoSyM
-
Membre du Steering Committee de la conférence ACM/IEEE MODELS
-
Chef du département informatique de l’IUT de Blagnac 2009 à 2012
-
Responsable de l’ancien module (Analyse et Conception des Systèmes d’Information)
-
Marié à une merveilleuse femme, papa d’une merveilleuse fille
2.5. Comment lire ce document?
Ce document a été réalisé de manière à être lu de préférence dans sa version électronique (au format HTML ou PDF), ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.
|
Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique! |
2.5.1. Conventions typographiques
J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :
-
Les références bibliographiques présentées en fin de document (cf. Bibliographie).
-
Les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons volontairement ces termes (e.g., Package).
Le titre des figures indique (entre parenthèses) un M pour les figures issues de Modelio, un MD pour les figures issues de MagicDraw, un P pour les figures issues de {plantumlweb}, un Py pour les figures issues de Papyrus, un R pour les figures issues de Rhapsody, un T pour les figures issues de TOPCASED, un Y pour les figures issues de yuml, et un UK pour les figures en anglais.
Pour les notes, conseils, avertissements, etc. voici la liste des pictogrammes utilisés :
|
|
Les notes comme celles-ci sont utilisées pour indiquer des éléments intéressant pour la majorité des lecteurs. |
|
Ces notes indiquent des points importants qui réclament votre attention. |
|
Celles-ci concernent en général des points de détail et permettent "d’aller plus loin". |
|
Définition : Exemple (OMG UML v2.4.1, p. 152)
Ces notes concernent des définitions tirées de la spécification UML™ et sont donc précisément référencées. |
|
Modélisation UML incorrecte. |
|
Modélisation UML partiellement correcte ou pouvant prêter à confusion. |
|
Modélisation UML correcte. |
2.6. Pourquoi parler de "document"?
Parce que j’ignore la version que vous êtes en train de lire. À partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :
-
Une version pour le web (Moodle) au format html
-
Une version pour présentation en amphi au format présentation
-
Une version pour impression au format pdf
2.7. Utilisation et autres mentions légales
Les images qui ne sont pas libres de droit contiennent un lien vers les sites où je les ai "empruntées".
N’hésitez pas à m’envoyer vos remarques en tout genre en m’écrivant ici.
2.8. Organisation et généralités
Ce support de cours est destiné en priorité aux étudiants de l’IUT de Blagnac.
Comme déjà indiqué, ce module est fortement corrélé au module de Conception et Programmation Objet Avancées (CPOA - M3105).
Il ne concerne que la partie modélisation du cours, les autres aspects étant couverts par Jean-Michel Inglebert. Il est prévu pour 2 cours d'1h30, complété par des mises en oeuvre en TD et en TP. Cette partie du cours va principalement porter sur UML™, le langage universel de modélisation très utilisé en entreprise que vous maîtrisez déjà en partie.
3. Introduction
La matrice qui nous servira de "carte de base" pour placer les activités ou les modèles, sera celle-ci :
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
Cette matrice permet de situer les différents éléments qui seront vus dans ce cours dans un cadre utile pour comparer ces éléments les uns aux autres. Je vous conseille de vous faire votre propre matrice. L’essentiel est de toujours bien se représenter les différents éléments qu’on aborde dans une carte mentale précise. Cela permet une meilleure mémorisation.
3.1. Points de vue
Dans un axe horizontal, j’ai différencié quatre grands points de vue :
- Requirements
-
Les exigences et leur prises en compte sont un éléments critique pour le succès du développement de tout système. Sans explorer l’ensemble des activités d’ingénierie système (ce qui nécessiterait tout un volume du type de Les exigences) nous insisterons ce semestre sur cet aspect.
- Structure
-
La description de l’architecture et des éléments constitutifs du système, avec les blocs, leurs relations, organisations internes, etc. constituera un point de vue important. C’est souvent la partie de modélisation qui pose le moins de problème aux débutants.
- Comportement
-
Le comportement d’un système est du point de vue de l’utilisateur final beaucoup plus important que la structure elle-même. C’est la partie qu’il est la plus à même d’exprimer, de comprendre (vos modèles) et de valider.
- Transverse
-
Un certains nombre de concepts sont transverses aux trois points de vue précédents. Il s’agira principalement de parler de cohérence ou de traçabilité entre les phases de développement ou entre les points de vue.
Ces différents points de vue ne doivent pas être confondus avec les différentes phases de développement (cf. paragraphe suivant). Ils sont plutôt à rapprocher de la notion de préoccupation. C’est ainsi que j’ai choisi de distinguer trois points de vue qui se retrouvent souvent en modélisation : le point de vue des exigences qui permet de se focaliser sur les besoins des clients ; le point de vue structurel qui permet de se focaliser sur les différents composants du système ; et le point de vue comportemental qui permet de se focaliser sur le comportement du système. Ces trois points de vue n’étant pas indépendants les uns des autres, j’ai intégré un quatrième point de vue transversal.
3.2. Phase de développement
Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :
- Organisation
-
Une étape indépendante du type de cycle de développement envisagé (en V, agile, etc.) mais qui concerne la mise en place d’un cadre de travail qui permette un développement de qualité (outils, éditeurs, gestionnaire de version, de tâches, etc.).
On pourrait rapprocher cette étape du "cycle 0" de Scrum.
- Analyse
-
Cette phase vise plutôt à examiner le domaine du problème. Elle se focalise sur les cahiers des charges et les exigences. L’analyse débouche sur un dossier d’analyse qui décrit les grandes lignes (cas d’utilisation, architecture principale) du système.
- Conception
-
Cette phase vise plutôt à examiner le domaine de la solution. Elle débouche sur un dossier de conception qui décrit les détails conceptuels de la solution envisagée (structure détaillée, comportement, etc.)
- Implémentation
-
Cette phase traite des développements finaux (construction ou approvisionnement en matériel, développement de codes, etc.).
Il s’agit ici classiquement des grandes étapes de développement d’un système. On pourrait être surpris par l’étape que j’ai appelé « organisation ». C’est une étape que je considère importante, particulièrement pour l’enseignement. Avant toute activité de modélisation ou de même de développement, il convient en effet de s’organiser en termes de choix d’outils, choix d’environnement, etc. Cette étape est souvent négligée par les étudiants. C’est pour cela que j’ai décidé de faire figurer cette étape de manière explicite. Bien sûr dans une organisation existante cette étape sera contrainte par les habitudes « maison ».
3.3. Questions de révision
|
|
4. Les exigences
L’ingénierie des exigences est d’une importance capitale, surtout en Ingénierie Système. En général les exigences sont exprimées par des ingénieurs dédiés à cette activité. La complexité des systèmes modernes (embarqués, communicants, critiques, …) rendent cruciale cette analyse.
|
|
Besoins, exigences : question de vocabulaire
La difficulté de l’emploi massif de l’anglais fait qu’il existe souvent une confusion entre les termes anglais et leurs traduction française. Nous précisons donc ici notre utilisation des termes :
|
Il est important pour une exigence qu’elle ne soit pas ambiguë (contrairement au terme "en" dans la consigne exprimée par la maman dans l’illustration ci-dessous : "Ramène moi 1 bouteille de lait. S’il y a des oeufs, ramène m’en 6.").
Dans le cadre de la matrice qui nous sert de plan, nous somme ici :
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
||||
Analyse |
||||
Conception |
||||
Implémentation |
4.1. Fondements
On abordera :
-
L’organization des Requirements
-
Les Requirements properties
-
Les Requirements links
-
Les Requirements Diagrams
-
Les considérations sur la traçabilité
-
Annotations des Requirements
-
Les Use Case Diagrams
|
|
L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]). |
4.2. SysML
4.2.1. Fiche d’identité
4.2.2. SysML, c’est…
- Un ensemble de 9 types de diagrammes
-
-
Diagrammes structuraux
-
Diagrammes de définition de blocs ({bdd})
-
Diagrammes internes de blocs ({ibd})
-
Diagrammes paramétriques ({par})
-
Diagrammes de packages (pkg)
-
-
Diagrammes comportementaux
-
Diagrammes de séquence ({seq})
-
Diagrammes d’activité ({act})
-
Diagrammes de cas d’utilisation ({uc})
-
Diagrammes d’états ({stm})
-
-
Diagramme d’exigence ({req})
-
- Un profil UML™
-
C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML™. Un exemple : le bloc SysML™ n’est qu’une redéfinition de la classe UML™.
- Une notation
-
Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.
4.2.3. SysML, ce n’est pas…
- Une méthode
-
En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML™ ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.
- Un outil
-
Nous verrons en effet que SysML™ ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.
- Un raton laveur
-
C’est juste pour voir ceux qui suivent…
|
|
On ne dit pas "le SysML" mais tout simplement "SysML". |
4.3. L’organisation des Requirements
Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML™ permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.
4.3.1. Représentation de base
Un Requirement en SysML™ n’est qu’un bloc particulier.
|
Définition : Requirements (OMG SysML v1.3, p. 139)
A requirement specifies a capability or condition that must (or should) be satisfied… A requirement is defined as a stereotype of UML Class… |
4.3.2. Différents types d’organisation
L’ingénierie des exigences aboutit généralement à une liste organisée d’exigences, que ce soit en terme de fonctionnelles/non fonctionnelles, de prioritaires/secondaires, etc. Le principal support de SysML™ à cette organisation, outre la possibilité de les annoter (cf. section Stéréotyper les exigences), consiste à utiliser les packages.
Plusieurs types d’organisations sont possibles :
-
Par niveau d’abstraction
-
Besoins généraux (en lien avec les use cases par exemple)
-
Besoins techniques (en lien avec les éléments de conception)
-
-
Par point de vue
-
Besoins principaux (en lien avec les use cases)
-
Besoins spécifiques :
-
Fonctionnels
-
Marketing
-
Environnementaux
-
Business
-
…
-
-
-
etc.
4.3.3. Tableaux de Requirements
Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.
|
|
Définition : Requirements Table (OMG SysML v1.3, p. 145)
The tabular format is used to represent the requirements, their properties and relationships… |
La plupart des outils modernes permettent le passage entre outils classiques de gestion des exigences (comme DOORS™) et outils de modélisation SysML™ (comme Modelio, illustré ci-dessous).
4.4. Les Requirements properties
Il est possible d’indiquer un certain nombre de propriétés sur un requirement :
-
priority (high, low, …)
-
source (stakeolder, law, technical, …)
-
risk (high, low, …)
-
status (proposed, aproved, …)
-
verification method (analysis, tests, …)
|
|
Dans le cadre du module MPA nous ne retiendrons comme attribut d’un requirement que son identifiant et le texte le désignnat (les deux attributs obligatoire). La priorité sera donné par le client en terme de cycle (on traitera en premier les requirements prioritaires). class ObtenirHoraires <<requirement>> {
Text = "Le logiciel doit fournir les horaires rapidement."
Id = "14.2"
}
|
4.5. Les Requirements links
Les principales relations entre requirement sont :
- Containment
-
Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").
- Refinement
-
Pour décrire un ajout de précision (
[refine]), comme par exemple une précision. - Derivation
-
Pour indiquer une différence de niveau d’abstraction (
[deriveReqt]), par exemple entre un système et un de ses sous-systèmes.
|
|
Lorsqu’une exigence possède plusieurs cas |
|
|
Il existe ensuite les relations entre les besoins et les autres éléments de modélisation
(les block ou les class principalement) comme |
4.6. Les Requirements Diagrams
Voici un exemple de {req} un peu plus étoffé, tiré de la norme (voir aussi Exemples de rationale et problem (tiré de SysML, UK)) :
4.7. Stéréotyper les Requirements
Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :
4.8. Annotations des Requirements
Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).
4.9. Les considérations sur la traçabilité
Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases
(en utilisant [refine] par exemple) et aux éléments structurels (en utilisant [satisfy] par exemple), mais ceci
sera abordé dans la partie transverse.
|
|
En général chaque requirement devrait être relié à au moins un use case (et vice-versa!). |
4.10. Les Use Case Diagrams
Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.
Ce diagramme est celui que vous avez appris l’an dernier en UML™.
|
|
Un acteur représente un rôle joué par un utilisateur humain. Il faut donc plutôt raisonner sur les rôles que sur les personnes elles-mêmes pour identifier les acteurs. |
4.11. Use case vs User story
-
Use Case
-
liste d’étapes
-
interactions entre un rôle et un système
-
fonctionnalités que doit fournir le système
-
-
User story
-
quelques lignes de texte décrivant une fonctionnalité
-
rédigées dans le langage commun (pas de terminologies techniques)
-
En tant que rôle je veux quoi afin de pourquoi.
-
-
Intérêt des UC ⇒ diagrammes et dépendances
-
Intérêts des Stories ⇒ centrée sur l’utilisateur
-
Pour aller plus loin : https://manurenaux.wp.mines-telecom.fr/2013/09/25/user-story-vs-use-case
4.12. Exigences et tests
4.12.1. Principes
Pour ce qui ce concerne ce module nous allons nous contenter de maintenir des matrices croisant les exigences d’un côté et les tests de l’autre.
Par exemple :
Dans la réalité, les entreprises industrialisent le processus de vérification des exigences en utilisant des outils adaptés. Illustration tirée de [TestsIndustriels2009] :
4.13. Exemple complet
En prenant un exemple tiré d’un exercice que vous avez traité l’an dernier voici un exemple cohérent :
4.13.1. Le texte du cahier des charges
Le texte complet de l’exemple ne précise pas le cahier des charges de l’Autoradio (AR), considérant que tout le monde sait ce que c’est!
Rédigeons tout de même quelques extraits (numérotés) de texte possible :
-
L’AR est un dispositif qui permet d’écouter la radio de manière confortable et interactive.
-
L’AR doit être capable de mémoriser un certain nombre de station différentes.
-
L’Utilisateur de l’AR doit pouvoir choisir sa station parmis un choix donné.
-
L’Utilisateur de l’AR doit pouvoir régler le niveau sonore.
-
L’Utilisateur de l’AR doit pouvoir chercher une station en "balayant" les ondes FM.
-
…
4.13.2. Expression des exigences
Nous pouvons, en analysant ce cahier des charges, déduire un certain nombre d’exigences. Nous les écrivons ici sous forme tabulaire, et en utilisant le langage Gherkin.
|
|
Version tabulaire :
Exemple de version textuelle formattée (fichier source ici):
#encoding: utf-8
Feature: Scénario simple d'utilisation de l'AutoRadio (AR)
In order to vérifier que le son marche
As an utilisateur lambda
I should be able to exécuter ces scénarios et constater les effets
Scenario: Augmenter le son
Given un AR avec le son à 0
When Je presse le bouton "Volume +"
Then Le son passe à 1
And Je commence à entendre la radio
4.13.3. Plan de test
Créer un plan de test consiste à prévoir l’ensemble des tests à l’avance de manière à prévoir la couverture de ces tests.
4.13.4. Analyse et la conception
Dans un cycle classique ("en V" par exemple), les modèles sont réalisés avant l’implémentation (codage).
Dans un cycle Agile, chaque cycle possèdera ses modèles, eux aussi versionnés, qui eux aussi évolueront en même temps que le code.
4.13.5. Lien et traçabilité
Plus encore que dans les méthodes classiques, il conviendra de vérifier que code et modèles sont bien cohérents. On pourra donc :
-
générer les codes à partir des modèles
-
générer les modèles à partir des codes (cf. Exemple de code Java commenté pour la génération automatique de diagrammes plantUML)
-
utiliser des outils intégrés comme eclipse
-
avoir un plan systématique de révision code/modèle
-
…
package demo;
class Controller {}
class EmbeddedAgent {}
class PowerManager {}
/**
* @extends Controller
* @extends EmbeddedAgent
* @navassoc - - 1..* PowerManager
* @note this is a note
*/
class SetTopController implements URLStreamHandler {
public String name;
int authorizationLevel;
void startUp() {}
void shutDown() {}
void connect() {}
}
/** @depend - friend - SetTopController */
class ChannelIterator {}
interface URLStreamHandler {
void OpenConnection();
void parseURL();
void setURL();
void toExternalForm();
}
4.14. En résumé
Les exigences sont très importantes en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML™.
| Requirements | Structure | Comportement | Transverse | |
|---|---|---|---|---|
Organisation |
⊕–, \<<deriveReqt>> |
|||
Analyse |
|
|||
Conception |
\<<allocate>> |
|||
Implémentation |
\<<satisfy>>, \<<verify>> |
En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. Exemple de démarche (SYSMOD Zigzag pattern)).
4.15. Concernant le projet
-
Je serai votre "référent" sur les aspects modélisation
-
Jean-Michel Inglebert sera votre référent méthodes agiles
-
Olivier Roques sera votre référent IHM et java
-
André Péninou sera votre référent client et exigences
4.16. Questions de révision
|
|
|
5. Cahier des charges utilisateur
5.1. Principe
Cette étape a pour but de préciser les attentes du client en définissant :
-
le problème posé,
-
son contexte et
-
les objectifs précis de l’application.
Cette étape débouche sur la production du cahier des charges utilisateur (CCU) de l’application qui, une fois validé par le client, permet de passer à l’étape suivante.
5.2. Liens avec le PTUT
-
Contactez votre client et prenez rendez-vous dès le résultat d’affectation des sujets de Ptut. Ne repoussez pas !!
-
Menez l’entretien avec l’outil simple de qualité QQOQCCP (qui, quoi, quand, où, comment/combien, pourquoi/pour quoi) comme check-list, pour faire le tour des besoins et ne rien oublier. Vous pouvez vous en inspirer comme d’une sorte de guide d’entretien.
-
Familiarisez-vous avec le modèle : http://fr.wikipedia.org/wiki/QQOQCCP
-
Lors de l’entretien : posez des questions, faites préciser, prenez des notes et synthétisez les réponses sur une feuille. Cela vous aidera pour dégrossir le travail de rédaction du cahier des charges.
-
Pensez de manière "stratégique" en replaçant les besoins exprimés par le client dans un contexte plus large interne (organisationnel) et externe (environnemental) pour en faire préciser et mesurer les enjeux :
-
En quoi est-ce important de réaliser ce projet ?
-
Que se passerait-il si ce produit/service n’était pas développé ?
-
Pourquoi cette demande aujourd’hui plutôt qu’hier ou demain ?
-
Prenez aussi contact avec votre superviseur qui a pour rôle de vous aider à piloter le projet dans ses diverses étapes.
-
5.3. Eléments de contenu de CCU
Pour rappel, voici la structure "classique" du cahier des charges (à adapter en fonction des spécificités de votre projet).
-
Exposé introductif
-
Présentation du domaine étudié
-
Motivations et objectifs du projet
-
-
Analyse de l’existant
-
MOT actuel (ou UC, DC, DS importants, SNI, …)
-
Description de l’architecture matérielle et logicielle existante
-
Description des données actuelles (fichiers, base de données, documents, …)
-
-
Analyse des nouveaux besoins
-
Diagramme des cas d’utilisation
-
Maquette des nouveaux résultats (états imprimés, écrans…)
-
Nouveaux besoins exprimés
-
Description des contraintes futures à respecter (performance, sécurité, …)
-
-
Annexes
-
Compte rendus de réunions ou d’interviews
-
Recueil des documents existants
-
Glossaire
Acronymes UML/SysML
act-
Raccourcis pour Diagramme d'ACTivité dans une cartouche SysML™
bdd-
Raccourcis pour Block Definition Diagram dans une cartouche SysML™
DC-
Diagramme de Classe UML™
DSS-
Diagramme de Séquence Système (un
sdoù seul le système dans sa globalité est représenté [1]) ibd-
Raccourcis pour Internal Block Diagram dans une cartouche SysML™
par-
Raccourcis pour Parametric Diagram dans une cartouche SysML™
pkg-
Raccourcis pour PaKaGe Diagram dans une cartouche SysML™
req-
Raccourcis pour REQuirements Diagram dans une cartouche SysML™
sd-
Raccourcis pour SEQquence Diagram dans une cartouche SysML™
stm-
Raccourcis pour STate Machine dans une cartouche SysML™
uc-
Raccourcis pour Use Case Diagram dans une cartouche SysML™
Définitions générales
|
|
Ressources
Les définitions ci-dessous sont regroupées à titre indicatif. Je vous invite à consulter les sources suivantes :
|
- DRY
-
Don’t Repeat Yourself : Un bon principe qui veut qu’on évite de répéter des tâches manuelles (comme les tests) en utilisant plutôt des scripts et des programmes.
- OMG
-
Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).
- TDD
-
Test Driven Development : Développements dirigés par les tests. On écrit les tests avant d’écrire le code. On travaille son code tant que les tests ne passent pas.
- TRL
-
Technology Readiness Level : Système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d’évaluer le niveau de maturité d’une technologie (cf. Wikipedia).
- STI2D
-
Sciences et Technologies de l'Industrie et du Développement Durable : série du baccarauléat qui met l’accent sur les technologies transversales et qui a introduit en 2011 l’enseignement de SysML™.
- SysML
-
System Modeling Language ™ : Le langage de modélisation de systèmes maintenu par l’OMG™.
- UML
-
Unified Modeling Language ™ : Le langage de modélisation généraliste maintenu par l’OMG™.
Liens utiles
-
Le site officiel d’UML™ : http://www.uml.org/
-
Un site très bien fait sur UML™ : http://www.uml-sysml.org/
Références
Voici quelques références utiles.
-
[ENS2013] L. Gendre et J.-M. Virely, SysML. Tutoriel du 13/06/2013. ENS Cachan.
-
[FIO2012] Fiorèse S., Meinadier J., Découvrir et comprendre l’ingénierie système, AFIS 2012.
-
[FMS] A. Moore, R. Steiner, S. Friedenthal, A Practical Guide to SysML, The MK/OMG Press, MK/OMG Press, 2011 (2nd edition).
-
[Fejoz2013] Loïc Fejoz. SysML4STI2D, présentation de SysML en STI2D, 2004. Disponible ici.
-
[Fowler2004] Martin Fowler. UML 2.0 INFORMATIQUE PROFESSIONNELLE, 2004.
-
[HAS2012] Haskins C., SE Handbook Working Group, INCOSE Systems Engineering Handbook: Version 3.2.2, International Council on Systems Engineering, 2012.
-
[Harmony] Bruce Powel Douglass. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development. Addison-Wesley Professional, 2009. ISBN-10: 0-321-54549-4
-
[KAP2007] Kapurch S., NASA Systems Engineering Handbook, 2007 (pdf).
-
[Modelio2012] Systems Engineering using Modelio, INCOSE 2012 Tool Vendor Challenge Case Study. Disponible ici.
-
[OMG2009] The Current State of Model Based Systems Engineering: Results from the OMG SysML Request for Information. Mary Bone and Robert Cloutier, 2009. Disponible ici.
-
[REQ2012] Guide Bonnes Pratiques en Ingénierie des Exigences, AFIS 2012.
-
[Roques2010] Pascal Roques. SysML par l’exemple - Un langage de modélisation pour systèmes complexes. Eyrolles. À obtenir ici.
-
[SeeBook2012] Embedded Systems Analysis and Modeling with SysML, UML and AADL, F. Kordon, J. Hugues, A. Canals, A. Dohet, Wiley, 2013.
-
[Sommerville1997] Ian Sommerville, Pete Sawyer. Requirements Engineering: A Good Practice Guide. Wiley, 1997.
-
[Styles] Scott W. Ambler. The Elements of UML 2.0 Style. Cambridge University Press, 2005. ISBN: 0-521-61678-6
-
[SysML] OMG. Systems modeling language version 1.3. Technical report, 2012. Available here.
-
[Walsh1999] Norman Walsh & Leonard Muellner. DocBook - The Definitive Guide. O’Reilly & Associates. 1999. ISBN 1-56592-580-7.
-
[TAOUP] Eric Steven Raymond. 'The Art of Unix Programming'. Addison-Wesley. ISBN 0-13-142901-9.
-
[TestsIndustriels2009] Guide méthodologique de l’industrialisation et référentiel de bonnes pratiques. Disponible ici.
À propos de ce document…
Document généré par Jean-Michel Bruel via Asciidoctor (version 1.5.2) de 'Dan Allen', lui même basé sur AsciiDoc.
Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.